The growth of the Internet appears to be exponential. Tens of thousands of networks are now connected to the Internet, and the number is close to doubling every year. Unfortunately, however, Internet Protocol (IP) addresses are not infinite and it is rather expensive to procure more IP addresses. With the increase in the number of users of the Internet, Telcos (Telecommunication companies) and ISPs (Internet Service Providers) are faced with an increasing shortage of IP addresses.
Each service to which a user may be connected has an associated IP address space. That is, a certain range of addresses may address that space. The range may be contiguous, discontiguous, or a combination of both. For example, Corp A may have an intranet service having all IP addresses which start with “10.1”—this may be denoted “10.1.x.x” where x can be any value. It may also be denoted “10.1.0.0; 255.255.0.0” where “10.1.0.0” represents the IP address and “255.255.0.0” represents the subnet mask. Those of skill in the art will recognize that a 255 in the subnet mask field represents a binary 1111 1111 and amounts to a requirement that the corresponding field of the IP address must match bit for bit in order to achieve a match. On the other hand, a 0 in the subnet mask field represents a binary 0000 0000 and amounts to no requirement for any match. For example, a service having an address space of “0.0.0.0; 0.0.0.0” represents the Internet, i.e., all IP addresses are within this space. Note that since the subnet mask is 0.0.0.0 the IP address could be set to any value and it would yield the same result.
The Dynamic Host Configuration Protocol (DHCP) has been developed to provide an automated assignment of IP addresses and to help solve the shortage of IP addresses. Conventional DHCP operation is as follows: When a DHCP client computer attempts an Internet connection, it broadcasts a DHCP request asking for any DHCP server on the network to provide it with an IP address and configuration parameters. A DHCP server on the network that is authorized to configure this client will offer an IP address by sending a reply to the client. Upon receiving this offer, the client may decide to accept it or wait for additional offers from other DHCP servers on the network. At the end, the client chooses and accepts one offer, and the chosen DHCP server sends an acknowledgement with the offered IP address having an associated “lease” time (and any other configuration parameters the client might have requested). During the lifetime of the lease, the client will repeatedly ask the server to renew. If the client chooses not to renew or if the client machine is shut down, the lease eventually expires. Once the lease expires, the IP address can be “recycled” and given to another machine.
The RADIUS (Remote Authentication Dial In User Service) protocol is typically used to authenticate a user and to associate the user with a remote domain and associated routing table. Like DHCP, RADIUS can also be used to assign an IP address to a remote user.
Point-to-Point Protocol (PPP) sessions are typically terminated on a home gateway, at a remote domain such as a virtual private network (VPN) and the owner of the remote domain is responsible for address assignment. In this case, a Network Access Server (NAS) is configured so as to implement DHCP-like functionality with IP address pools so as to dynamically allocate IP addresses. The NAS distributes IP addresses to users (end-users of the Telco or ISP) when the users log-in. The NAS also revokes IP addresses when the users log-out, making those IP addresses available to other users.
The network edge is the point where customer traffic enters a service provider's network. Traffic can arrive at the edge via access technologies including dial, IP, ATM, Frame Relay, leased line, wireless, Digital Subscriber Line (xDSL) and cable. An edge switch or edge router aggregates traffic from all or some of these access interfaces and forwards packets over a multiplexed packet network core.
Service providers have begun handling management of IP addresses for owners of remote domains. In these cases, PPP sessions are terminated at the service provider's premises on an edge router. The owner of the remote domain provides the service provider with a pool of IP addresses to manage on behalf of the remote domain. An edge router of the service provider assigns IP addresses to remote users (users of the remote domain) as needed. Whenever an edge router assigns an IP address to a remote user, it must insert a route to that user in a routing table designated for the remote domain. This update must be propagated to corresponding routing tables in each edge router in the network. This is explained below in more detail with reference to FIG. 1.
FIG. 1 is a flow diagram that illustrates a typical method for allocating IP addresses. At 100, a service provider receives a pool of IP addresses from an owner of a remote domain such as a virtual private network. At 105, each pool of IP addresses is divided into per-remote domain local IP address pools on each edge router that is configured to accept PPP sessions from remote users of the remote domain. At 110, a determination is made regarding whether an IP address from a remote user has been received. If an IP address from a remote user has been received, at 115 an unused IP address from a local IP address pool designated for the remote domain being connected to is assigned to the remote user. At 120, a route to the remote user is inserted into the corresponding edge router routing table. If an IP address from a remote user has not been received, at 125 a determination is made regarding whether an IP address has been returned. If an IP address has been returned, the IP address is returned back to its designated IP address pool at 130 and the route to the remote user is removed from the corresponding routing table at 135.
However, maintaining routing information for each IP address is expensive with respect to network bandwidth consumption because each time an address is added or removed, the event must be broadcast so that other network entities know which edge router is handling the address. Moreover, this problem of bandwidth consumption increases and becomes more acute during peak use hours. Additionally, the routing tables grow larger and more difficult to manage as the size of the network grows.
An improvement is made possible by statically configuring local IP address pools on each edge router. Each edge router includes at least one local IP address pool designated for a remote domain. Each edge router also includes a routing table for each remote domain supported by the edge router. Local IP address pools are divided into groups of contiguous IP addresses or subnets. Summarized routes corresponding to all subnets in an address pool are inserted into the edge router routing table associated with the pool. Local IP address pools allow relatively efficient route summarization because fewer routing table updates are required. This explained below in more detail with reference to FIG. 2.
FIG. 2 is a flow diagram that illustrates an improved method for allocating IP addresses using statically configured local IP address pools. At 200, a service provider receives a pool of IP addresses from a remote domain to manage on behalf of the remote domain. At 205, each pool of IP addresses is divided into per-remote domain local IP address pools on each edge router that is configured to accept PPP sessions from remote users of the remote domain. At 210, summarized routes corresponding to subnets in the address pool are statically inserted into the routing table associated with the pool. At 215, a determination is made regarding whether an IP address request has been received from a remote user. If a an IP address request has been received, at 220 an unused IP address is assigned from a local IP address pool designated for the remote domain being connected to. If an IP address has not been received, at 225 a determination is made regarding whether an IP address has been returned. If an IP address has been returned, at 230 the IP address is returned to its designated IP address pool.
Unfortunately, statically configured local IP address pools have their own disadvantages. It is possible to overutilize IP addresses for one edge router-remote domain combination while simultaneously underutilizing IP addresses for another edge router configured to accept connections for the same remote domain. For example, suppose edge router 1 and edge router 2 are configured with 10 IP addresses each for connections to a particular remote domain. Once edge router 1 allocates all 10 IP addresses, further requests to edge router 1 from remote users of the remote domain will result in denial of service, even if edge router 2 has allocated only 2 of its 10 IP addresses.
As mentioned above, both the DHCP and RADIUS protocols can be used to assign IP addresses. However, these protocols assign a host address to a remote user. The edge router can be configured to autosummarize the host routes before redistributing them. Unfortunately, route summarization is inefficient in this case because remote users log on and off indeterminately, making it difficult to have a contiguous set of IP addresses that can be summarized. Furthermore, it takes time to propagate a newly inserted route to all edge routers. A remote user has limited connectivity during this period. Another disadvantage is that updates must be sent to each edge router whenever a remote user logs on or off.
What is needed is a solution that provides dynamic and relatively efficient allocation of remote domain IP addresses between one or more edge routers. A further need exists for such a solution that uses open and well-understood standards.